---
id: split-db
title: 9.28 分表分库
sidebar_label: 9.28 分表分库
---

import useBaseUrl from "@docusaurus/useBaseUrl";

:::important 特此声明

本章 `9.28.2` 至 `9.28.5` 小节挪用博主：[雨点的名字](https://www.cnblogs.com/qdhxhz/) 的 [分库分表 - 理论](https://www.cnblogs.com/qdhxhz/p/11608222.html) 博客内容。**特此声明。**

:::

## 9.28.1 应用场景

数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作增删改查的开销也会越来越大。

另外，由于无法进行分布式部署，而一台服务器的资源（CPU、磁盘、内存、IO 等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

这个时候就需要对数据库或数据表进行拆分。

数据切分可以分为：`垂直切分` 和 `水平切分`。

## 9.28.2 垂直切分

垂直切分又可以分为: 垂直分库和垂直分表。

### 9.28.2.1 垂直分库

根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。

<img src={useBaseUrl("img/dbsplit1.jpg")} />

:::note 说明

一开始我们是单体服务，所以只有一个数据库，所有的表都在这个库里。

后来因为业务需求,单体服务变成微服务治理。所以将之前的一个商品库，拆分成多个数据库。每个微服务对于一个数据库。

:::

### 9.28.2.2 垂直分表

把一个表的多个字段分别拆成多个表，一般按字段的冷热拆分，热字段一个表，冷字段一个表。从而提升了数据库性能。

<img src={useBaseUrl("img/dbsplit2.jpg")} />

:::note 说明

一开始商品表中包含商品的所有字段，但是我们发现:

1.商品详情和商品属性字段较长。2.商品列表的时候我们是不需要显示商品详情和商品属性信息，只有在点进商品商品的时候才会展示商品详情信息。

所以可以考虑把商品详情和商品属性单独切分一张表，提高查询效率。

:::

### 9.28.2.3 优缺点

- 优点

  - 解决业务系统层面的耦合，业务清晰
  - 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
  - 高并发场景下，垂直切分一定程度的提升 IO、数据库连接数、单机硬件资源的瓶颈

- 缺点

  - 分库后无法 Join，只能通过接口聚合方式解决，提升了开发的复杂度
  - 分库后分布式事务处理复杂
  - 依然存在单表数据量过大的问题（需要水平切分）

## 9.28.3 水平切分

当一个应用难以再细粒度的垂直切分或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。

水平切分也可以分为：水平分库和水平分表。

### 9.28.3.1 水平分库

上面虽然已经把商品库分成 3 个库，但是随着业务的增加一个订单库也出现 QPS 过高，数据库响应速度来不及，一般 mysql 单机也就 1000 左右的 QPS，如果超过 1000 就要考虑分库。

<img src={useBaseUrl("img/dbsplit3.jpg")} />

### 9.28.3.2 水平分表

一般我们一张表的数据不要超过 1 千万,如果表数据超过 1 千万，并且还在不断增加数据，那就可以考虑分表。

<img src={useBaseUrl("img/dbsplit4.jpg")} />

### 9.28.3.3 优缺点

- 优点

  - 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
  - 应用端改造较小，不需要拆分业务模块

- 缺点

  - 跨分片的事务一致性难以保证
  - 跨库的 Join 关联查询性能较差
  - 数据多次扩展难度和维护量极大

## 9.28.4 数据分片规则

我们考虑去水平切分表，将一张表水平切分成多张表，这就涉及到数据分片的规则，比较常见的有：Hash 取模分表、数值 Range 分表、一致性 Hash 算法分表。

### 9.28.4.1 Hash 取模分表

一般采用 Hash 取模的切分方式，例如：假设按 goods_id 分 4 张表。（goods_id%4 取整确定表）

<img src={useBaseUrl("img/dbsplit5.jpg")} />

**优缺点**

- 优点

  - 数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈。

- 缺点

  - 后期分片集群扩容时，需要迁移旧的数据很难。
  - 容易面临跨分片查询的复杂问题。比如上例中，如果频繁用到的查询条件中不带 goods_id 时，将会导致无法定位数据库，从而需要同时向 4 个库发起查询，
    再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。

### 9.28.4.2 数值 Range 分表

按照时间区间或 ID 区间来切分。例如：将 goods_id 为 1-1000 的记录分到第一个表，1000-2000 的分到第二个表，以此类推。

<img src={useBaseUrl("img/dbsplit6.jpg")} />

**优缺点**

- 优点

  - 单表大小可控
  - 天然便于水平扩展，后期如果想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片的数据进行迁移
  - 使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题。

- 缺点

  - 热点数据成为性能瓶颈。
    例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询

### 9.28.4.3 一致性 Hash 算法

一致性 Hash 算法能很好的解决因为 Hash 取模而产生的分片集群扩容时，需要迁移旧的数据的难题。具体原理可参考 [https://www.cnblogs.com/duhuo/p/4996105.html](https://www.cnblogs.com/duhuo/p/4996105.html)

## 9.28.5 分库分表带来的问题

任何事情都有两面性，分库分表也不例外，如果采用分库分表，会引入新的的问题：

### 9.28.5.1 分布式事务问题

使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求，这里就不多说。

### 9.28.5.2 跨节点关联查询 Join 问题

切分之前，我们可以通过 Join 来完成。而切分之后，数据可能分布在不同的节点上，此时 Join 带来的问题就比较麻烦了，考虑到性能，尽量避免使用 Join 查询。

解决这个问题的一些方法：

- **全局表**

全局表，也可看做是 "数据字典表"，就是系统中所有模块都可能依赖的一些表，为了避免跨库 Join 查询，可以将 这类表在每个数据库中都保存一份。这些数据通常很少会进行修改，所以也不担心一致性的问题。

- **字段冗余**

利用空间换时间，为了性能而避免 join 查询。例：订单表保存 userId 时候,也将 userName 冗余保存一份，这样查询订单详情时就不需要再去查询"买家 user 表"了。

- **数据组装**

在系统层面，分两次查询。第一次查询的结果集中找出关联数据 id，然后根据 id 发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。

### 9.28.5.3 跨节点分页、排序、函数问题

跨节点多库进行查询时，会出现 Limit 分页、Order by 排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；

当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。

### 9.28.5.4 全局主键避重问题

如果都用主键自增肯定不合理，如果用 UUID 那么无法做到根据主键排序，所以我们可以考虑通过[雪花 ID](https://www.cnblogs.com/qdhxhz/p/11372658.html) 来作为数据库的主键，

### 9.28.5.5 数据迁移问题

采用双写的方式，修改代码，所有涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写，

边写边按时间比较数据是不是最新的。

## 9.28.6 如何实现

:::caution 特别说明

由于分表分库不仅仅需要内置代码的支持，同时还需要集成数据库中间件，这里推荐 `MyCat` 中间件。[MyCat 官方网站](http://www.mycat.org.cn/)

:::

`Furion` 框架中提供了轻量级的 `分表分库` 支持：

- **动态切换数据库**

```cs
// 直接改变数据库
repository.ChangeDatabase("数据库连接字符串");

// 通过数据库上下文定位器切换
repository.Change<Entity, MyDbContextLocator2>();
```

如需跨库查询，需用到数据库技术，如 `SqlServer` 链接服务器或同义词。

- **动态切换数据库表**

第一步、配置数据库上下文特性`[AppDbContext( Mode=DbContextMode.Dynamic)]`

第二步、需要动态修改表名的实体继承 `IEntityMutableTable<TEntity>` 接口，并实现 `GetTableName()` 返回表名方法

最后通过 `BuildChange<TEntity>` 切换即可。

```cs
var rep = repository.BuildChange<Persion>();
```

调用 `BuildChange` 方法之后会自动调用 `GetTableName()` 方法。

:::note 了解更多

想了解更多 `DynamicModelCacheKeyFactory` 知识可查阅 [EF Core - 多个模型之间交替](https://docs.microsoft.com/zh-cn/ef/core/modeling/dynamic-model) 章节。

:::

## 9.28.7 反馈与建议

:::note 与我们交流

给 Furion 提 [Issue](https://gitee.com/dotnetchina/Furion/issues/new?issue)。

:::
